Estaba leyendo   y quería publicar un comentario, pero sentí que esto justifica un artículo de respuesta. Primero, si no me conoces, he escrito un montón de código fuente abierto. Toda la plataforma y algo más. Creo que la opinión general que se expresa en ese artículo y muchas de las tonterías que veo en línea son demasiado simplistas y peligrosas. este artículo  Necesitamos que nos paguen  ¿Quién pagará tu salario?  Las personas tienen varias respuestas para los modelos comerciales de código abierto. Por ejemplo, "consultoría" o el vago "apoyo". Siempre me pregunto si esas personas alguna vez intentaron vender consultoría. O tal vez "apoyo".  La gente no compra estas cosas. Especialmente en una economía en recesión. La forma en que los vendedores suelen vender estas cosas es la insinuación de que podría violar una licencia y sería mucho más fácil si pagara y obtuviera la licencia comercial. Incluso daré el "soporte" de forma gratuita. Sí, puede obtener algunos patrocinadores si pasa todo su tiempo en el teléfono. Es un proceso de ventas interminable. Persiguiendo pistas y haciendo llamadas. Manejar este tipo de negocio requiere muchos gastos generales.  Algunos desarrolladores utilizan licencias de código abierto problemáticas que luego pueden aprovechar para las ventas. Pero luego son vilipendiados como "no lo suficientemente abiertos". Ahí no se gana.  Sun Microsystems pagó mi salario durante parte de mi trabajo de OSS. Se hundieron y cayeron de una valoración de más de 200 mil millones de dólares, y finalmente se vendieron a alrededor de 7 mil millones. De acuerdo, no es porque fueran de código abierto. Eso es solo una anécdota, y no ayudó. Las personas reales pierden sus trabajos reales porque el código abierto no genera dinero. Incluso cuando lo hace, hace muy poco. La gente solía decir que termina con una porción más pequeña de un pastel más grande. Esto es cierto, pero solo se aplica a los grandes jugadores y tienes dos opciones: convertirte en el gran jugador o ver cómo un gran jugador se lleva las ganancias de tu arduo trabajo.  No me malinterpreten, no estoy en contra de las personas que se benefician de mi trabajo o incluso de las grandes corporaciones. Hago OSS por diversión y me encanta la idea de que la gente triunfe en base a mi trabajo. Pero entiendo la frustración que sienten muchos desarrolladores, y la "defensa del código abierto" general que veo en la gente es problemática.  Cebo y cambio  Lo malo es el cinismo empresarial. Toma Google. Abren Android de código cuando no tenía usuarios. Las empresas construyeron sobre él y también lo hicieron los desarrolladores. La defensa se formó a su alrededor porque "es de código abierto". Luego lanzaron Google Play Services de código cerrado, que luego agregó el requisito de SaaS Firebase para algunas funciones esenciales (es gratis para eso en este momento) y ahora tenemos dependencias profundas de código cerrado de proveedores que se hacen pasar por código abierto.  No   Google Play Services si queremos construir para Android. Por supuesto. Pero hace que sea mucho más difícil crear una aplicación de Android y si no la usa para algunas cosas (por ejemplo, empujar, comprar, etc.), entonces está prohibido en el mercado de Android más grande. La gran mayoría de los desarrolladores "simplemente lo usan". Esto significa que cualquiera que quiera borrar Google Play de su dispositivo Android a favor de una solución 100 % de código abierto; encontrará que tienen muy pocas opciones de software para aplicaciones. tenemos que usar  Tome la búsqueda elástica. Eran de código abierto y lo mataban. Pero AWS se estaba bifurcando y realmente no estaba ayudando a su resultado final. Así que Elastic cambió su licencia para bloquear AWS. AWS comenzó su propia bifurcación. Algunas personas vilipendian a Elastic en esta historia, pero esas personas probablemente nunca tuvieron que luchar contra Amazon por la supervivencia de su negocio. En este caso, ambas partes usaron el código abierto como arma en una pelea comercial.  El caso de Java es ligeramente diferente. Java no era de código abierto y se hizo de código abierto más tarde. Todavía mantuvo IP sobre el idioma. Así que entiendo algo del férreo control de Oracle sobre el proyecto y lo acepto. Es bueno que haya una mano firme en el barco y contribuyó al éxito de Java. El problema con la demanda de Google fue que Oracle trató de ampliar su IP para incluir las API. Eso fue un error.  GPL es la mejor licencia  Hace aproximadamente una década, una startup llamada RoboVM lanzó un compilador de código abierto que traducía Java a aplicaciones iOS nativas. Fue genial y hablé bastante con el fundador de JavaOne. En ese entonces, estábamos considerando construir nuestra propia VM o elegir una solución como RoboVM. Terminamos con el primero y creamos nuestra propia máquina virtual, que era mucho más simple y se adaptaba mejor a nuestras necesidades (   ). también es de código abierto  Esa decisión se basó en méritos técnicos y creo que valió la pena, pero aún tengo un gran respeto por el equipo de RoboVM. Mi preocupación era Apple. Rompen muchas cosas... Construir una máquina virtual de bajo nivel es un peligroso juego del gato y el ratón en el que Apple cambiaría algo de repente y nos quedaríamos atascados. Una preocupación secundaria era la monetización. Comprendí que el equipo de RoboVM tendría que pagar los salarios de sus empleados y fundadores de alguna manera. ¿Cómo se gana dinero con un compilador de código abierto? Tenga en cuenta que esto fue hace una década y no había ningún precedente como   que pudiéramos ver como plantilla. Zig  En algún momento, mis temores sobre las políticas de Apple se materializaron y Apple agregó un requisito de código de bits al apuntar a algunas plataformas. RoboVM pasó una gran cantidad de tiempo trabajando en la compatibilidad con códigos de bits y decidió cerrar su código fuente. Comprendieron que no pueden financiar el desarrollo continuo sin él. No tome esto como un juicio hacia su decisión. Entiendo totalmente que, como dije, monetizar OSS es   difícil. muy  La GPL protegió a la comunidad al obligar a RoboVM a publicar el código de la versión final antes de la migración del bitcode. Esto permitió algunas bifurcaciones del código en años posteriores, pero aún no se mantiene. La compañía fue comprada por Xamarin y descontinuada rápidamente cuando Microsoft compró esta última. Sin la GPL, el código podría haber sido inaccesible. También obligó a terceros a publicar su código.  En este sentido, creo firmemente en GPL en lugar de licencias más permisivas como MIT, BSD, Apache, etc. Creo que nosotros, como comunidad, deberíamos preferir una licencia que preserve los derechos de la comunidad en lugar de los derechos corporativos. También proporciona una buena opción de monetización para el creador del proyecto. Simplemente vuelva a obtener la licencia como una licencia propietaria y cobre por eso. Desafortunadamente, la GPL es a menudo un punto de partida para muchos desarrolladores porque asumen incorrectamente que es malo para ellos. El opuesto es verdad. La GPL es una de las mejores formas de preservar los derechos de la comunidad a largo plazo.  ¿Han cambiado las cosas?  Mencioné a Zig antes. Hay muchos otros ejemplos de bases que tuvieron éxito, como SQLite, Mozilla, etc. Llegar a este punto suele ser difícil y no necesariamente funciona para todos los proyectos de código abierto. Por ejemplo, casi todo el mundo usa cURL, pero no creo que veamos una base cURL. También tenga en cuenta que todos estos proyectos se basan en centros tecnológicos de EE. UU. Desde mi experiencia, es mucho más difícil conseguir patrocinadores en otros territorios.  ¿Significa esto que todo el código abierto debe ser un pasatiempo o un mega proyecto que lo abarque todo?  Desafortunadamente, no tengo buenas respuestas. Pero tengo un problema: los defensores entusiastas del código abierto. ¡No estás ayudando!  El código abierto se está convirtiendo en un juego exclusivo para empresas. Se utiliza como arma entre las empresas tecnológicas que luchan. Hay un nombre para esto en el comercio minorista: líder de pérdidas.  En el comercio minorista, una gran tienda de supermercado vendería algunos productos a pérdida y anunciaría este precio increíblemente bajo. Esto atrae audiencias que compran otras cosas en el camino, por lo que el supermercado termina obteniendo ganancias. Pero la razón de esto es ahogar a la competencia. La competencia parece cara (ya que no pueden vender con pérdidas). Se van a la quiebra, y la gran empresa minorista aumenta los precios. Inicialmente, parece que obtuvimos un trato tremendo de la competencia, pero al final terminamos perdiendo. Por eso, algunos reguladores prohíben este tipo de prácticas, ya que acaban destruyendo un mercado.  El código abierto es utilizado de manera similar y cínica por las grandes tecnológicas. Forman “comunidades” mediante la contratación de ejércitos de profesionales de relaciones con desarrolladores para crear una mascarada de entusiasmo de base. A veces no necesitan monetizar el mercado, es suficiente para mantener fuera a la competencia.  TL;RD  Me encanta el código abierto y creo que es muy importante. Es por eso que no debemos permitir que las corporaciones lo conviertan en un arma. Necesitamos diversidad dentro del ecosistema y necesitamos apoyar proyectos críticos más pequeños. La idea de "descuentos" para proyectos de código abierto o "consultoría" no es sostenible.  Las grandes corporaciones utilizan el código abierto como arma para luchar entre sí, parece que nos beneficiamos a corto plazo. Pero a medida que ganan, la mentalidad corporativa se hace cargo y duplican el control.  Las soluciones que sugiero son:  Use GPL: está aquí para proteger los derechos de la comunidad. No es de extrañar que a las corporaciones no les guste.  No sea un puritano de OSS: las pequeñas empresas necesitan ganar dinero. Ofrecerán SaaS, extensiones de código cerrado, etc. Está bien.  Las grandes corporaciones no son benévolas: la defensa que veo en torno a los proyectos de OSS de las empresas FAANG (MAANG) es problemática. No son compatibles con OSS. Lo usan y lo aprovechan. No me malinterpreten, estoy agradecido por su código y es maravilloso que lo publiquen. Pero debemos ser cautelosos, tienen requisitos fiduciarios que pueden chocar con hacer lo "correcto" según los estándares de OSS.  No sé si lo próximo que haré será OSS. No sé si elegiré GPL ya que, como dije, la gente tiene problemas con eso. Pero sé esto: si eres un defensor del código abierto. Afina la retórica. No es útil.   También publicado   . aquí

Shai is a Developer Advocate at Lightrun, where he's busy explaining why hotfixing just to add a log line needs to be a thing of the past. He is also a JavaOne rockstar that has been developing software professionally for ~30 years, a published author, an open-source hacker (founder and long-time maintainer of Codename One) , an experienced Java trainer and a public speaker. When he's not in front of his machine you can find him making food for his two kids or doing Yoga with his wife (well, at least attempting to).

2021 - HackerNoon Contributor of the Year - DEBUGGING

2022 - HackerNoon Contributor of the Year - Coding Skills

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Software Testing

Debug Agent

Buy My Book

Learn on my YouTube Channel

Read My Stories

Newsletter

Follow me on Twitter

Author/DevRel/Entrepreneur/Hacker

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Cebo y cambio de código abierto

Cebo y cambio de código abierto

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps